Within the IP (Internet Protocol) Multimedia Subsystem (IMS) as defined by 3rd Generation Partnership Project (3GPP) Session Initiation Protocol (SIP) defined by Internet Engineering Task Force (IETF) is used for controlling communication. SIP is an application-layer control protocol for creating, modifying, and terminating sessions with one or more participants. These sessions may include Internet multimedia conferences, Internet telephone calls, and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. Diameter protocol has been defined by IETF and is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility.
Different types network entities and functions exist in the IMS network. Call Session Control Functions (CSCF) implement a session control function in SIP layer. The CSCF can act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating CSCF (I-CSCF). The P-CSCF is the first contact point for the User Equipment (UE) within the IMS; the S-CSCF actually handles the session states in the network; the I-CSCF is mainly the contact point within an operator's network for all IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area.
The functions performed by the I-CSCF are, for example, assigning an S-CSCF to a user performing SIP registration and routing SIP requests received from another network towards the S-CSCF. The S-CSCF performs the session control services for the UE. It maintains a session state as needed by the network operator for support of the services and may be acting as Registrar, i.e. it accepts registration requests and makes its information available through the location server (e.g. HSS). The S-CSCF is the central point to users that are hosted by this S-CSCF. The S-CSCF provides services to registered and unregistered users when it is assigned to these users. This assignment is stored in the Home Subscriber Server (HSS).
The HSS is the master database for a given user. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions. As an example, the HSS provides support to the call control servers (CSCFs) in order to complete the routing/roaming procedures by solving authentication, authorisation, naming/addressing resolution, location dependencies, etc.
The HSS is responsible for holding the following user related information:                User Identification, Numbering and addressing information;        User Security information: Network access control information for authentication and authorization;        User Location information at inter-system level: the HSS supports the user registration, and stores inter-system location information, etc.;        User profile information.        
Call forwarding or call diversion is a service in which the called user may activate a service to forward/divert an incoming call or session to new destination if predetermined conditions exist. These conditions may be e.g. that the called user does not answer, or is busy or that incoming calls are always forwarded. In IMS network upon detecting a call forwarding, the S-CSCF procedure stops executing the services of the served or called user (the user who has activated call forwarding) and does not allow the execution of any further services. However in some cases it may necessary to execute the originating services of the served user after the call forwarding (diversion) is detected.
Solutions to this situation have been discussed before. First proposal is so called P-Served-User based approach which has been discussed in IETF document draft-vanelburg-sipping-served-user-01 and in related discussion paper discussed at CT#48 (document number C1-071596).
P-Served-User approach proposes to use the “orig” parameter to indicate that originating services of the served user must be executed.
However, this solution may cause problems: if originating and terminating S-CSCF functionalities are separated, the returning request is routed to an originating S-CSCF, which will consider the request as a returning request (the original dialog identifier is there), but either does not have the related dialog or (if the calling party is served by the same S-CSCF) the related dialog serves the calling party and thus the original dialog identifier is not acceptable for that dialog (or it is accepted and S-CSCF assumes that the request is returning from the application server (AS) after performing the originating service of the calling party, although the AS already served the forwarding party).
Another proposed solution is SIP History-Info based approach discussed in IETF document RFC 4244 and in related discussion paper discussed at CT#48 (document number C1-071682).
History-Info approach proposes to use the existence of the SIP History-Info header to indicate that originating services of the served user must be executed. This proposal also has drawbacks. If an AS works according to the supplementary service specification for Call Diversion, then it must add the History-Info and still may intend to indicate that originating services are not needed. Also it is possible that History-Info is already in the message (although S-CSCF after detecting call forwarding may check whether the last entry of the History-Info header includes the served user or not)
Both approaches propose a solution where the AS controls the service execution (by inserting “orig” parameter/History-Info header), this may enable smart users to skip e.g. barring service.
The object of the invention is to overcome the above drawbacks